RAID systems that span multiple controllers are referred to as “network RAID”. The purpose of RAID systems is to provide data redundancy, so that a single RAID module failure will not result in lost data. When a RAID module fails abruptly (either due to software error or hardware failure) it can leave inconsistent parity/mirror stripes, which can be repaired. As recognized herein, however, if these stripes are not repaired before a subsequent failure(s) then data loss will occur.
In many RAID systems, client devices, also referred to herein as “hosts”, are connected to multiple storage controllers. Data redundancy is maintained across controllers in accordance with RAID principles, with software being executed on each controller to coordinate layout and access to data and its recovery on component failure. By virtualizing physical storage from these controllers, the software provides shared access to data from multiple clients and allows managing for scaling of capacity, performance, and availability.
As understood herein, a challenge to allowing clients to share access to data is the potential for inconsistent updates to the physically distributed redundant data. Consider a RAID-5 layout for shared data between two clients. When a client wishes to write to a file, the relevant data block as well as the associated parity block must be updated. This operation is done in two phases. In the first phase, the old data and parity is read. In the second phase, the new data and the adjusted parity are written to the storage devices. But if two clients happen to concurrently write, then a wrong interleaving of the two phases of each write can lead to an inconsistent parity, which can occur even when the clients are writing to disjoint logical address ranges. The relationship between data and parity is introduced due to the layout and requires atomic parity update for correctness.
Another source of inconsistent parity occurs when a client fails in the middle of its second phase of a write operation. In that case, it might have sent out a command to write new data but before it can send out the command to write the new parity (or vice versa). In both cases, the end result is that the data and parity blocks are inconsistent. If a storage device in the system fails before this inconsistency is repaired, then data loss will occur.